With recent improvements in processor, storage and networking technologies, today's wireless communications devices take many different forms, and offer a number of innovative features. Examples of this new class of wireless communication devices include personal digital assistants (“PDAs”) fitted with a wireless communications interface, two-way paging devices, digital communications devices, and third-generation (“3G”) personal communicators.
Gone are the days when such devices are merely used to support verbal communication. Today, consumers are demanding that such devices be multifunctional, enabling a user to receive and/or retrieve email, to send/receive text messages, and to access text-based content from the Internet (e.g., stock quotes, flight arrival/departure information, etc.). Despite the recent innovation in the wireless communication space, consumers are demanding even greater application resources and functionality for their portable communication devices.
Heterogeneous Network
FIG. 1 illustrates an example of a heterogeneous network 100 comprised of a wireline component 110 and a wireless component 130. The wireline component 110 includes a wireline link 112 to the Internet 102 (or other network) and a wireline-to-wireless gateway 120. It also includes a wireline link 114 to the Internet 102 (or other network) and an Internet server 104. The gateway 120 includes a host computer 122 and wireless transmitter 124. The wireless component 130 of the heterogeneous network 100 includes a wireless link 132 between the gateway 120 and wireless devices 140. These devices may include any wireless portable devices, such as a laptop computer, a mobile telephone, a PDA, and the like.
In this heterogeneous network 100, data packets with their accompanying headers are sent from the server 104 through the wireline link 114, through the Internet 102, through the wireline link 112, and to the gateway 120. The gateway sends the packets and their headers via the wireless link 132 to the wireless devices 140.
It is a challenging task to transmit massive amounts of data (e.g., streaming media content) over such a heterogeneous network. One reason is that the transport-layer-protocol associated with each of the disparate components was developed independent of one another and, therefore, without regard for many of the design challenges of the other.
For example, the control algorithm of a typical wireline transport-layer-protocol (e.g., TCP, UDP, etc.) assumes that any degradation in transmission quality (e.g., packet loss) is due to congestion problems in one or more of the network elements (e.g., router, switch, hub, etc.). Accordingly, conventional transport-layer-protocols will iteratively reduce the transmission rate until transmission quality is improved.
However, in heterogeneous networks that include a wireless network component, the degradation in transmission quality may have nothing to do with congestion on the wireline component of the communication channel. That is, the degradation in transmission quality, measured in terms of a bit-error rate (“BER”), may well be caused by a fading condition, a shadowing effect, multi-path sources, long round-trip-times (RTT), etc. in the wireless communication channel.
Since conventional wireline transport-layer-protocols assume that degradation in transmission quality is the result of congestion, its default reaction is to reduce the transmission rate. However, such reaction will not improve transmission quality when the actual problem is a fading condition in the wireless component of the communication channel. The same is true for the other conditions that produce BER in the wireless communication channel.
The bandwidth of wireless links is always scarce due to properties of the physical medium and regulatory limits on the use of frequencies for radio communication. Therefore, it is necessary for network protocols to efficiently utilize the available bandwidth.
Despite such limitations, conventional transport-layer-protocols are often employed to provide the Internet content available to wireless devices. As a result, the wireless Internet access user experience is often disappointing. This is because wireless Internet access is unable to fully utilize the limited bandwidth available because of the repeated reduction in transmission rates resulting from the inherent BER of the wireless link.
TCP/IP Headers
The most common transport-layer-protocol on the Internet is TCP/IP. It is used for both wireline and wireless communication channels. However, one problem with using TCP/IP over wireless links is the large header overhead. For example, a typical TCP/IP packet has, in addition to link layer framing, an IP header (twenty octets in IPv4 and forty octets in IPv6), a TCP header (twenty octets) for a total of forty octets in IPv4 and sixty octets in IPv6. According to proposals for new protocol standards, future generations of TCP/IP will include larger headers.
The header size is a significant per-packet penalty for wireless system. This means that in light to the available bandwidth and the frequency of BERs, which necessitate retransmissions, the per-packet overhead for the header is significant. Therefore, it is desirable to reduce the header size to make low-bandwidth wireless applications more efficient. Thus, the header may be reduced by compressing it. Since a typical TCP header includes a portion of data that does not change frequently with successive headers, the headers may be compressed to a size significantly smaller than their original size.
In general, it is desirable for the header of a transport-layer-protocol (such as TCP/IP) to be losslessly compressed so that the decompressed header is identical to the header before compression. In addition, it is desirable for the header to be compressed with a high compression ratio. See “RFC 2507” (M. Degermark, B. Nordgren, and S. Pink, “IP Header Compression”, Internet RFC 2507, February 1999 at www.ietf.org/rfc/rfc2507.txt?number=2507) for general background information regarding header compression.
However, compressed data is less tolerant to non-trivial data loss. As mentioned before, wireless links have an inherent degradation in transmission quality, which introduces non-trivial data loss. This data loss degree is generally represented as bit-error rate (“BER”) and may be the result of fading condition, a shadowing effect, multi-path sources, long round-trip-times (RTT), etc. This degradation makes conventional transport-layer-protocol header compression (such as that of the TCP/IP header) perform poorly.
Conventional Header Compression and Transmission Schemes
In FIG. 1, the gateway 120 is the header-compressor (“HC”) and the wireless device 140 is the header-decompressor (“HD”). The wireless device 140 is also considered the “receiver” over the wireless link 132. The gateway 120 compresses the header before sending it over the wireless link 132. The wireless device 140 de-compresses the header when it receives the compressed header.
In general, network transport-layer protocol header compression and transmission (“HCT”) maintain contexts of a flow at both the HC and the HD sides, which contain relevant information to compress and decompress the packet header correctly. Normally, the HD will keep strictly synchronized with the HC, thus it can decompress the compressed packet header correctly.
But under some conditions, the HD's context may be inconsistent or out-of-sync with the HC (e.g., the packet losses due to the link error). Because of this inconsistency, the successive packets cannot be decompressed correctly and will be dropped eventually. This effect, so-called “error propagation,” will last until the contexts are brought into synchronization. This will degrade the performance of network transport-layer protocol (such as TCP), especially on relative high BER link, such as wireless channel.
Examples of conventional schemes for compressing the header of a transport-layer-protocol (such as TCP/IP) include “VJHCT”, “IPHCT”, and “FBHCT.”
VJ Compression and Transmission (VJHCT) Scheme
For TCP, the original proposed header compression scheme is Van Jacobson's header compression algorithm, VJHCT, defined in Van Jacobson, “Compressing TCP/IP headers for low-speed serial links”, Internet RFC 1144, February 1990 at www.ietf.org/rfc/rfc1144.txt?number=1144.
Following the transmission of the first uncompressed TCP/IP header, only the encoded difference to the preceding header, is transmitted. In most cases, VJHCT can compress the 40 octets full TCP/IPv4 header to only 4 octets and improves the TCP performance significantly on bandwidth-limited links. However, due to the differential encoding, once a delta is lost on the link between the HC and the HD, a series of packets rebuilt upon the HD's inconsistent context will be discarded eventually at the receiver end.
During this period, no acknowledgment will be sent back to the TCP receiver, thus the TCP's self-clocking nature is broken. As a result, the TCP sender is forced into a timeout. When used over wireless links, VJHCT causes frequently timeout and thus degrades TCP performance significantly.
In the VJHCT scheme, the HC 120 and HD 140 are strictly synchronized to ensure the correct reception of the compressed headers. The HC 120 sends data packets with their accompanying compressed headers via a data channel 152, which is typically a simplex serial link. Via a feedback channel 154, the HD 140 returns feedback indicating whether the headers were successfully received and decompressed.
The VJHCT scheme uses delta coding in header compression and is highly dependent upon the strict synchronization between HC 120 and HD 140. A loss of strict synchronization typically leads to incorrect packets dropping at the HD side, which in turn cause TCP retransmissions and even timeout. In the case of wireless links, error induced strict synchronization loss is very frequent. Such loss significantly degrades the performance of TCP.
The VJHCT scheme relies on transmitting only the difference from the previous header in order to reduce the large overhead of TCP/IP header. Considering the high BER in wireless channels, if a packet gets lost, the compressed header of next packet cannot be correctly decompressed. Then the HD must send the request for resynchronization and in the meanwhile discard the current compressed header. A serious result of this effect is that it prevents the “TCP Fast Retransmit” algorithm from being fired and causes TCP retransmission timeout.
IP Header Compression and Transmission (IPHCT) Scheme
The IPHCT scheme is a low-loss TCP/IP header compression scheme that is based on VJHCT. It is described in more detail in RFC 2507 (cited above). Besides few modifications on VJHCT, IPHC adds two mechanisms: the TWICE algorithm and the explicit header-request mechanism.
The TWICE algorithm is a local context repair mechanism. It assumes that only the sequence number or acknowledgment number changes during the connection and the deltas among consecutive packets remain constant in most cases. However, such assumptions are not always true, especially when timestamp and SACK options are added in the TCP header. It is hard for TWICE algorithm to recover the context by simply applying the previous delta twice to the context only.
For explicit header-request mechanism, a feedback channel from the HD to the HC is needed. When the HD fails to repair the context, it may optionally send a CONTEXT_STATE packet back to the HC to indicate that one or more contexts are invalid. Upon receiving such requests, the HC will send full TCP/IP headers to re-synchronize the contexts. The IPHCT scheme needs at least a link round-trip time to recover from the inconsistency. On some links with relative high bandwidth and long round-trip time, such as wireless WAN, there are several additional packets dropped before the context is repaired by explicit header request. This may lead to a rather long TCP Fast-Recovery period or timeout when there are not enough flying segments on the end-to-end path.
Fixed-Base Header Compression and Transmission (FBHCT) Schemes
The FBHCT schemes are discussed in Stephen Pink, Matt Mutka, “Dependency Removal for Transport Protocol Header Compression over Noisy Channels”, In Proceedings of ICC'97; and Anna Calveras-Augé, Miquel Arnau-Osorio, Josep Paradells-Aspas, “A Controlled Overhead for TCP/IP Header Compression Algorithm over Wireless links”, In Proceedings of Wireless'99.
These schemes attempt to reduce the loss of strict synchronization by removing the dependence that is implicitly transmitted on the link. The interpacket dependency is eliminated by using a fixed base, or reference. Thus, once the HD and the HC agree on the same base, a single corrupted packet doesn't affect the rebuilding of the successive packets.
Although these schemes are more robust to link errors than VJHCT and IPHCT are, the introduced overhead reduces its effectiveness over noiseless channels. The FBHCT schemes haven't provided a solution to control such overhead in a practical way. In the meanwhile, the FBHCT schemes are not completely free from the inconsistency once the fixed base is lost on the link.
Conventional Schemes Require Strict Synchronization
These conventional TCP/IP header compression and transmission schemes are insufficient and inefficient. That is because they require strict synchronization between the transmitting HC and the receiving HD so that the HC can be sure that the HD received the header and received it correctly. Such strict synchronization is typically implemented by a feedback channel (such as channel 154 in FIG. 1).
Strict synchronization, however, slows down the already bandwidth-limited wireless link. It is inherently slower than an asynchronous (or inferentially synchronized) technique because the sender (e.g., HC 120) is waiting for the receiver (e.g., HD 140) to respond.
Strict synchronization is slow because of the intrinsic high BER and long RTT of wireless communications results in frequent loss of strict synchronization between the HC and HD. This sync-loss forces the HC to resend uncompressed headers (i.e., TCP retransmissions) to reestablish synchronization. High BER of wireless communication causes sync-loss when there are errors in compressed packets received by the HD. Long RTT of wireless communication causes a communication delay while the HC waits for the HD to specifically request a resend of a full header.
What is needed is a header compression and transmission technique that does not rely on strict synchronization between the HC and the HD but can, nevertheless, refresh the context when the HD lose the synchronization completely.